What other mechanism do you think might be appropriate? What criteria do you think apply to the selection of process?

My thought here was that, if we were writing this several years ago I would have put just the IANA process here. When the W3C process arrived, I would have wanted it to be written in such a way that the W3C process were also acceptable. I don't know of another process that would fit now, but there's also no reason that only 2 organizations would be acceptable.

On the other hand, maybe this is an extensibility point for the design principles, and we can just update the design principles instead of defining a registry of registry mechanisms with criteria for adding new ones.

The extension point that is governed by a registry needs to be fully-specified. That includes a definition of what to do if an item is not understood (is there a negotiation mechanism? is there feature detection? is the extension ignored when it is not understood? or, does it cause a failure of some sort?)

RFC 6709 goes into some detail about some of the extension models that might apply. Those are for protocols, but the same principles broadly apply to APIs as well.

Then, the requirements for what it takes to define the extension need to be clearly defined, as you say here.

I've rearranged some things to add this in, and to defer to RFC 6790 for details. How does it look?

This isn't quite the angle I'd use here. The extent to which you can add tighter constraints varies based on the ecosystem you are deploying into. If your implementers are browsers, then you might imagine that a tighter set of restrictions might be respected and therefore it would be more reasonable to at least try it on.

If you are looking at websites implementing, then you can almost guarantee that registrations won't happen, even if the constraints are very lightweight.

Getting that nuance in might be a good idea.

Good point. I replaced the tail of this paragraph with this discussion, and added a paragraph saying (roughly) that if this is likely, then it can justify a FCFS-with-no-spec policy.

Extensions for optional features - ones that are simply ignored if not understood - don't need this.

You should say that where the functioning of a specification depends on choosing and using an registered value, then you have three choices:

• One party implements all the options.
• You mandate a baseline that all parties implement.
• Risk interoperability failure if the intersection of options between entities is empty.

And that's for a two-party negotiation. There are many things that the W3C documents where there are more than two potential actors involved.

I tried to incorporate optional features.

I feel like we should only endorse one of your three choices:

• having 1 party implement all options means that party gets a veto on new options ... maybe it's saying that all values have to be marked as required for one side of the protocol so that the other side can make a free choice ... and in that case, values can only be added in a revision of the main spec, so it's not a registry anymore.
• the baseline is equivalent to requiring at least 1 entry
• We shouldn't endorse a plan that leads to interoperability failures.

XML namespaces use URIs (not URLs). They are not using URIs for their ability to resolve to something; most XML namespace URIs, if they are resolved, point to nothing useful. You seem to imply that they could point to something; some do, but that's never been the goal.

They use URIs because the domain into which they are being deployed does not benefit from centralized coordination. They need identifiers and a way to generate them without coordination or - save us all - namecoin-style consensus. Indeed, it would be a mistake to require centralized coordination for those (doubly so for a wasteful distributed consensus). XML is a file format that is used by many people for many reasons. There is no value in asking people to coordinate identifier allocation. The same applies to JSON-LD, for similar reasons ¹.

But the question we need to answer here is different. If you are specifying an extension to a protocol, why would you use a registry rather than letting the proverbial thousand flowers bloom? That all comes down to how you conceive of the interoperability goals of the extension point.

An optional, ignorable extension might benefit from a registry if there is a greater need to have different implementations agree on what the meaning of the extension is. In TLS, we have a registry for extensions, not just because there is a limited space available, but because the goal of defining an extension is to enable a shared understanding of the space.

In comparison, the IPTC metadata format uses URLs, because they don't see a need to constrain the space of options. There, the risk that people define multiple identifiers that are close, or even identical, in meaning is something that is tolerated so that there is a low-coordination way of adding metadata for limited or proprietary uses.

An extension point that determines everything that follows, like TLS ciphersuites or digital credential protocols, benefits more from coordination than something that can be readily ignored. Those are places where mandating implementation of a core by all (or a subset by browsers) is necessary.

XML namespaces use strings that by convention often look like URLs and might parse as one, if we're going to quibble about details.

After some of the rewrites above, the paragraph about URIs/URLs wound up fitting in as a thing one might do if the alternative is a specification-less registry. They're hierarchical in the IETF sense, but they also tend to risk a DNS entry being bought out from under the original creator. And they're usually more bytes than really necessary, but that's petty and I didn't find a convenient way to work it in.

The IPTC example seems like a case where they should have defined the main terms in the main spec, or possibly done a hierarchical space where each "Recommended/used Prefix" is controlled by a particular entity.

Or are you thinking that we should call out the case of enabling local/proprietary extensions as a time when URLs are actually the right way to go?

That's not interoperability in the sense that we should care about here.

https://www.w3.org/TR/ethical-web-principles/#oneweb

I'm happy to drop this sentence, although DIDs might be an example where there are many specifications (protocols) that have fields in which a DID could appear, and each of those specifications needs to mandate at least 1 DID Method to be implemented, but not all of those specifications need to agree on the same Method. I don't think that would violate the One Web principle, although it also wouldn't be ideal.

My thought here was that, if we were writing this several years ago I would have put just the IANA process here. When the W3C process arrived, I would have wanted it to be written in such a way that the W3C process were also acceptable. I don't know of another process that would fit now, but there's also no reason that only 2 organizations would be acceptable.

On the other hand, maybe this is an extensibility point for the design principles, and we can just update the design principles instead of defining a registry of registry mechanisms with criteria for adding new ones.

I've rearranged some things to add this in, and to defer to RFC 6790 for details. How does it look?

Good point. I replaced the tail of this paragraph with this discussion, and added a paragraph saying (roughly) that if this is likely, then it can justify a FCFS-with-no-spec policy.

I'm happy to drop this sentence, although DIDs might be an example where there are many specifications (protocols) that have fields in which a DID could appear, and each of those specifications needs to mandate at least 1 DID Method to be implemented, but not all of those specifications need to agree on the same Method. I don't think that would violate the One Web principle, although it also wouldn't be ideal.

I tried to incorporate optional features.

I feel like we should only endorse one of your three choices:

• having 1 party implement all options means that party gets a veto on new options ... maybe it's saying that all values have to be marked as required for one side of the protocol so that the other side can make a free choice ... and in that case, values can only be added in a revision of the main spec, so it's not a registry anymore.
• the baseline is equivalent to requiring at least 1 entry
• We shouldn't endorse a plan that leads to interoperability failures.

After some of the rewrites above, the paragraph about URIs/URLs wound up fitting in as a thing one might do if the alternative is a specification-less registry. They're hierarchical in the IETF sense, but they also tend to risk a DNS entry being bought out from under the original creator. And they're usually more bytes than really necessary, but that's petty and I didn't find a convenient way to work it in.

The IPTC example seems like a case where they should have defined the main terms in the main spec, or possibly done a hierarchical space where each "Recommended/used Prefix" is controlled by a particular entity.

Or are you thinking that we should call out the case of enabling local/proprietary extensions as a time when URLs are actually the right way to go?